Several leading technology organizations are investing in building technologies that sell “software-as-a-service”. Such services provide access to shared storage (e.g., database systems) and/or computing resources to clients or subscribers. Within multi-tier e-commerce systems, combinations of different types of physical and logical resources may be allocated to subscribers and/or their applications, such as whole physical or virtual machines, CPUs, memory, network bandwidth, I/O capacity, or bundled resources such as database servers, scientific computation clusters, and the like.
In many cases of bundled services, the core functions of the service are performed at secure servers or hosts, which may be termed back-end service nodes, that typically cannot be accessed directly from client devices. For example, in the case of network-accessible database services, a number of storage nodes may be established to store client database contents and to perform various types of reads, writes and other data extraction or manipulation operations on behalf of the clients. The clients may typically submit their work requests (e.g., read requests or write requests) to shared front-end intermediary nodes, which may be responsible for performing various types of validation operations on the request, and (for validated requests) transmitting internal representations of the work requests to the appropriate service nodes. At least in some environments, a given back-end service node may also be shared among several clients.
A number of factors may influence the implementation of such network-accessible services. For example, clients' throughput and response time requirements may have to be taken into account when deciding the set of resources to be allocated for the back-end and/or front-end service nodes for a given client. Although sharing the resources of a given node among multiple clients may be conducive to high overall levels of resource utilization, such sharing may at least in some cases have side effects that clients may prefer to avoid. Another important consideration, especially for provider networks that implement modern software development processes that involve frequent service software upgrades, is the potential impact of software upgrades on service stability.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.